回到 Day 13 那二十七封信。

其中有幾封是「非得由懂資安的人看過才能判斷」的？大概兩封。

剩下二十五封，機器可以先處理掉絕大部分。這一層就叫 L0。

**L0 的定義很窄：不需要資安知識就能完成的整理工作。**它負責讓案件變得可判斷，判斷本身是明天的事。

必填欄位是整層 L0 的槓桿

先講最有效的一件事，因為它決定後面所有事情的成本。

一封只寫「你們某台機器有漏洞」的信，你要來回問三次才能開始研判：哪個型號、什麼版本、怎麼重現。每一次來回是一到兩天，而如果這件事真的構成第 14 條，那幾天就是從你的 24 小時裡扣掉的。

**表單能強迫必填，信件不行。**這就是 Day 14 為什麼要有網頁表單。

建照送件有一份書圖文件檢核表。件不齊，櫃檯直接退件，連掛號都不受理。這個設計常被抱怨，但它的邏輯很清楚：**收件檢核只看齊不齊，不看設計好不好。**好不好是後面審查委員的事，兩件事分開，才不會讓櫃檯人員替委員做判斷。

L0 就是那個櫃檯。

**最重要的是第五、第六欄。**其他欄位影響研判效率，只有這兩欄直接決定法定時限：前者影響案件走不走軌一，後者決定你有多少時間。

設計上有一條硬規則：**必填欄位不要超過七個。**超過之後通報者的放棄率會明顯上升，而放棄的人不會消失，他會改走 Day 13 講的影子流程——直接找工程師的個人帳號，或者直接公開。那時候你連知悉的時間點都控制不了。

「風險」那一欄比「能處理掉」那一欄重要。

尤其是第二列。過濾規則寫嚴一點，雜訊就少一點，但誤殺一封真通報的代價是你在不知情的狀況下錯過了知悉的時間點。

所以 L0 有一條原則：**隔離，不刪除。**所有被擋下來的東西留存至少九十天，而且可以回查。CRA 的知悉爭議一旦發生，第一個要翻的就是這批東西。你要能證明「這封信在這個時間進來、被規則歸類為垃圾、當時的規則長這樣」。刪掉了，就只剩各說各話。

自動確認回覆只寫三句話

**第一句，收到了。**時間戳記要有。

**第二句，案件編號。**這是最容易被省略、也最有價值的一句。有編號，通報者後續追問有依據；對你來說，那是稽核軌跡的起點。

**第三句，下一步與時間。**寫「三個工作日內給你初步回覆」，不要寫「我們會盡快處理」。前者是承諾，後者是廢話，而研究人員讀得出差別。

有一件事不要寫進自動回覆：**任何關於嚴重程度的判斷。**自動回覆是機器發的，機器不該替公司對外表達立場。

L0 最容易犯的錯：讓它開始判斷

寫到這裡你可能會想，既然都自動化了，不如順便讓它判個級。

兩件事會壞。

**第一，誤判會被自動化放大。**人判錯一件是一件，規則判錯是一整類，而且會一直錯下去，直到有人發現。

第二，稽核時說不清楚是誰做的判斷。「系統自動判定為低風險」在市場監管機關面前很難解釋，尤其當那件事後來出事了。

L0 的輸出應該是**「已去重、已補齊欄位、已分類到某一軌的案件」**，而不是「已定級的案件」。定級是有名字的人做的事。

交付物：通報表單必填欄位規格

把上面那張欄位表拿去給網頁的人，加三欄。

三個提醒。

**第一，型號下拉選單的選項要接產品清單。**接不上就先寫死，但要有人負責更新。選單裡沒有的型號，通報者會選「其他」然後在描述裡打字，你就回到原點了。

**第二，「至少 50 字」這種驗證要設，但不要設太高。**它擋掉的是「你們有漏洞請聯絡我」這種釣魚式來信，不是真的通報者。

**第三，最後一欄請認真填。**這張表最終要變成資料庫欄位，欄位對不上，你的案件系統就只是一個裝了 PDF 的資料夾。

明天 Day 16：L1，五個問題決定它去哪

L0 整理完之後，第一個人要在幾分鐘內判斷這件事走哪一軌。五個問題，順序不能換。也講一個很常見的坑：intake 這個角色通常排在編制後段。

順便問一句。你們現在收到弱點通報：

平均要來回幾次才問得到型號跟版本？

（a）通常一次就齊　（b）兩到三次　（c）三次以上　（d）沒收過，所以不知道

留個字母就好，不用打長篇。（d）的話今天這篇正好是最好的起點，因為你可以直接照著設計，不用先拆掉舊的。

這系列每天更新，覺得有用的話幫忙訂閱一下，謝謝。

參考：Regulation (EU) 2024/2847 第 14 條與 Annex I Part II(5)(6)；ISO/IEC 29147 弱點揭露。欄位設計、L0 動作與保存期建議為個人整理，非法規明文。